Tools have been developed in recent years to aid in the design verification of hardware and software systems, for example software suites, hardware circuitry, and programmable logic designs. “Design verification” refers to the act of reviewing, testing, or otherwise determining and documenting whether the design output meets design input requirements. In order to assure that the design complies with its requirements, it is common to generate a large number of input or instruction sequences to assure that the design operates as intended under a wide variety of circumstances. In general, test systems produce a report indicating whether tests have been passed or failed, and in some cases, may even indicate a module that is estimated to be faulty.
Conventionally, to test a device under development (such as a mobile information device), or to test software designed to run on such a device, a developer connects the device to an appropriate test system. The target device under test may be connected to the test system either directly or via a communication emulator. The developer selects a battery of test programs to run on the target device while monitoring its behavior. Running the complete battery of tests can commonly take many hours or even days. This problem is particularly acute in testing low-end computing devices, such as cellular telephones and other mobile information devices, which have limited computing power and memory resources due to their small size. Thus, testing on the target device can become a serious bottleneck in the development cycle.
Moreover, the conventional test architecture does not address the needs of operators as compared to developers. Some device testers may test devices on private networks in which the test device is connected directly to a test workstation, or at least the test device and test workstation are located on the same private network. In contrast, an operator may wish to perform device testing on a test device located on a publicly accessible network. For example, a cellular telephone service provider may wish to test telephones on their publicly accessible cellular network using test workstations in their company network. However, in conventional systems, the test workstation would typically have to be located outside of the company firewall because the test device cannot breach the company firewall to communicate with the test workstation. This results in security risks because the test workstation is no longer protected by the firewall. Sensitive information on the test workstation would be left vulnerable to theft by hackers. For example, the test workstation may use a secret encryption key for communication with the test device. That secret key would be vulnerable to theft if located on a test workstation outside of the firewall.